| ||
|
Editorial Today's News News Archives On-line Articles Current Issue Magazine Archives Subscribe to ISD Directories: Vendor Guide 2001 Advertiser Index Event Calendar Resources: Resources and Seminars Special Sections Information: 2001 Media Kit About isdmag.com Writers Wanted! Search isdmag.com Contact Us |
|
Internet Changes Office Imaging Requirements
By Beranard Stamme
The Internet facilitates instant updating and distributing of documents, a huge advantage when handling up-to-date information and data. The availability of fast, inexpensive, and high-quality color printers will also eventually change the way we handle production printing (news magazine, brochures, catalogs) in the future, moving from the current "high volume printing in central locations and distribute" to an Internet based "distribute and print locally" production print model.
This print model requires network-ready printers that have-in addition to the legacy IEEE-1284 parallel port (about 1 MByte/s) and the more recent USB 1.1 (up to 12 Mbit/s) interfaces-10/100 Mbit Ethernet integrated as a standard feature. The IEEE-1394 interface (up to 400 Mbit/s) as well as the future USB2.0 interface (up to 480 Mbit/s) will provide adequate throughput for faster print engines. Additionally, efforts are underway to enable wireless printing utilizing wireless local area network (LAN) technology like IEEE-802.11b or wireless personal area network (PAN) technology like Bluetooth. Thin clients like PDAs and cellular phones may require the printer to have both a high-speed wired connection to a server (to process content rich print jobs), and a relatively slow speed wireless interface like Bluetooth for communication with the PDA (to identify the print job, specify the web address for the document and the appropriate print server).
Advancements in color laser printers (output quality and speed) and the migration to digital copiers (color laser copiers) make them credible candidates for replacing monochrome network printers. For home users, the determining factor for buying a color laser printer is probably the price (compared to inkjet and monochrome laser), which must currently fall below $1,000 for wide market penetration.
The processing requirements for color printers are at least four times higher compared to monochrome printers at equivalent page rates. Color printers usually have four process colors (cyan, magenta, yellow, and black) instead of one (black)-some actually use more than four process colors.
A color printer (four-color CMYK) with a resolution of 1200 dpi (dots per inch) may require more than 60 MB of image data for standard letter size paper. An engine with a page rate of 16 pages per minute requires these 60 MB of image data to be generated and transferred to the engine in less than 4 seconds. The actual raw data generation requirements are usually much higher and depend on the imaging technique (resolution enhancement, color correction, half-toning) that is being applied.
The printer market is very cost sensitive. Price developments have been closely aligned to the PC price trends. Most laser printers (monochrome as well as color) on the market today utilize embedded processors, with MIPS being the dominant architecture in today's market.
The design requirements
CPU, I/O, and memory bandwidth requirements, as well as the need for a low-cost solution, point to system-on-a-chip (SOC) designs for printer and digital copier applications. Today, "generic" intellectual property (IP) like CPUs and interfaces like USB, Ethernet, 1394, and PCI are available from multiple sources. Printer manufacturers strive to differentiate their products primarily through superior output quality and print speed. They apply proprietary IP to accelerate image processing (page description to raster conversion) and to enhance image quality (resolution enhancement, half-toning, dithering). An SOC design that combines the generic IP and proprietary IP represents the most cost-effective solution. There is no real value in designing these standard blocks from scratch.
Time-to-market considerations, as well as IP verification and integration, are key issues when deciding on an SOC approach. The reuse of available IP along with flexible and expandable IP interconnect architecture are equally important.
The integration of IP from several different sources can require significant design effort that may reduce the overall value of using third-party IP in the first place, especially for IP of relatively limited complexity. Aside from this effort, the necessary verification effort can turn out to be even more labor intensive and can potentially uncover design issues and verification holes that need to be solved in concert with the IP vendor.
Taking these important issues into consideration, it's prudent to select an interconnect bus that has been widely adopted in the industry. This selection provides increased and independent verification by a number of different users/vendors at the same time-and provides higher verification coverage, which facilitates better IP quality and reusability.
LSI Logic (Milpitas, CA) has adopted the Advanced Micro-controller Bus Architecture (AMBA) 2.0 as the interconnect bus for it's IP CoreWare library. LSI Logic has worked closely with ARM Ltd. (Cambridge, U.K.) on the AMBA 2.0 specification to ensure manufacturability and testability. The AMBA bus puts emphasis on modular system design, thus improving processor independence. LSI Logic implements the AMBA's advanced high-performance bus (AHB)/advanced peripheral bus (APB), which is based on multiplexed bus architecture with single edge clock reference, compared to the tri-state bus architecture used in previous AMBA bus implementations (see Figure 1).
Characterizing the bus
The AMBA bus width definition is flexible allowing 32-, 64-, and 128-bit wide buses. The following discussion and figures illustrate an AMBA based chip architecture implementing a 32-bit wide AHB and APB bus. AMBA's AHB connects high-performance and high clock frequency system modules, while featuring multi-master capability, burst transfers, and split transactions.
The objective of AHB is to allow the transfer of data between a master and a slave. AHB masters can initiate transfers to or from a slave by providing an address within peripheral address space. AHB slaves provide or accept data from masters when selected.
A slave can delay data transmission or return error codes. Examples of AHB masters are processors like ARM or MIPS processor cores or other DMA (Direct Memory Access) capable peripherals like Ethernet MACs or USB host/device controllers.
The main AHB signals are:
HCLK bus reference clock
HADDR address
(generated by AHB master)
HWRITE Transfer direction:
read/write
(generated by AHB master)
HREADY Transfer complete response
(generated by AHB slave)
HWDATA Write Data Bus
(from AHB master to AHB slave)
HRDATA Read Data Bus
(from AHB slave to AHB master)
A basic AHB transfer occurs when a single data transfer is read from or written to a slave. The data size can be a Byte, a Half-Word (2 bytes) or a Word (4-bytes).
In addition to the above signals, the AHB control and status signals are:
HRESP Transfer status
(generated by AHB slave)
HBURST Burst mode
(generated by AHB master)
HTRANS Transfer status
(generated by AHB master)
HSIZE Burst length
(generated by AHB master)
HPROT Protection type
(generated by AHB master)
The AHB peripheral may deliver/
accept data immediately or may insert wait states by asserting the HREADY signal. Slave returns also transfer
status via the HRESP signals, the status can be:
OKAY: transfer successful - default response to signal transfer completed successfully.
ERROR: unsuccessful transfer-indicates that an abort has occurred (for instance, access to a non-existent memory location).
RETRY: Slave can't perform operation immediately; master should re-attempt access later.
SPLIT: request queued by slave-slave will notify when ready to provide/accept data, used to break a multiple transfers (burst).
The major difference between retry versus split is that the retry operation simply indicates that the slave isn't ready; the master may retry at any time. Alternatively, split operation involves a more complex protocol through which the slave notifies the arbiter when it is ready. A split transaction is an optional slave feature and requires complex logic in the slave. Simple slave implementations cannot include split functionality and only return OKAY or ERROR responses.
In order to prevent a deadlock situation in the case of all AHB master receiving split responses, bus ownership will be granted to a default AHB master. A slave can provide a split response to more than one master-a queue of two masters to be serviced.
During basic AHB transfers, address and control lines are sampled on clock rising edge. Since slave-decoding logic is combinatorial, at the end of an addressing cycle, a slave detects if it has been selected and which internal location has been addressed (basic AHB write transfers).
Sampling the data
After sampling the address, the slave must determine whether it will be able to provide or accept data in the next cycle and assert HREADY accordingly; otherwise wait states need to be inserted (by asserting the HREADY signal low).
Although it is possible to insert more than one wait state, it should be noted that this would hold up bus operations. Alternatively, a write buffer can be incorporated into the slave to reduce the possibility of wait states for write operations, or the RETRY return code response can be used to free the bus.
For AHB Burst transfers, the burst type is encoded in the HBURST signals, which are outputs from AHB masters and synchronous with the addresses. The available burst modes are:
(INCR), 4 words, 8 words, or 16 words; or
The AHB HTRANS signals provide the current transfer status to the AHB slave and arbiter and can have the following values:
The AHB burst length is encoded in the HSIZE signals and it ranges from 8 bits (1 byte) to 1024 bits (32-words). It is asserted together with the first address of a burst and remains stable until the end of the burst. The HSIZE signals can be sampled by the arbiter to determine how long it needs to grant the bus to the master. The slave can sample the HSIZE signals in order to determine burst boundaries and access type (byte/half-word or word). The AHB HPROT signals encode the type of protection for the current memory operation including:
The AHB master arbitration uses the following signals: HREQ Bus Request (generated by AHB master) HGNT Bus Granted (generated by AHB arbiter) HLOCK Bus Locked (generated by AHB master) HMASTER Identifies currently active master (generated by AHB arbiter) HMASTLOCK Master performs locked transfer (generated by AHB arbiter) The AHB slave decoding uses the HSEL signals: HSEL Slave Select (generated by AHB Slave decoder) All peripherals are memory-mapped. The slave is selected by decoding the selection of slave as based on most significant bits of the address. The remaining bits of the address are decoded by the slave. In case of a read operation (data read from peripheral), the slave decoder output is used to enable the peripheral and select the appropriate slave multiplexer input. In case of a write operation, the HSEL signals are used to enable a slave. Only the enabled slave must accept write data. A default slave is used to provide an error response when an un-mapped memory space is being addressed. HSPLIT SPLIT completion request (generated by AHB Slave) AMBA's APB is intended for connecting slower system models and low bandwidth peripherals for minimal power consumption and reduced interface complexity. All bus signals are related to clock and a slower bus clock (than the AHB bus clock) can be used. AHB masters don't interface directly with APB peripherals, but communicate via a bridge (APB-bridge). The APB-bridge is a slave for the AHB subsystem and the only master in the APB subsystem. The APB-bridge is assigned a memory space inside the main memory; APB peripherals are mapped to it. All memory transfers to APB peripherals are being routed on the AHB to the bridge. The bridge selects and routes to the correct peripheral. The main APB signals are: PCLK Peripheral Clock, PCLK can be a multiple of HCLK, controlled by APB bridge PADDR Peripheral Address PWRITE Peripheral Transfer Direction (Read/Write) PSELx Peripheral selection, similar to HSELPWDATA Write Data Bus (to peripheral) PRDATA Read Data Bus (from peripheral) PENABLE Peripheral Data Enable All APB transfer operations last two PCLK cycles. During the first cycle, the APB bridge asserts the address, and during the second cycle PENABLE. During write operations, the APB peripheral consumes data. During read operations, the APB peripheral provides data. An APB peripheral can't insert wait states (see Figures 2 and 3). APB transfer operations aren't pipelined. The address remains present during the second clock cycle (data phase). The APB PCLK can have a different frequency (slower) than HCLK. In this case, the APB bridge asserts the required number of wait states. Connecting peripherals to the APB bus facilitates reduced complexity of AHB slave decoder. With increasing design complexities, the verification effort grows dramatically more complex as well. The reuse of verification environments (functional bus models, test benches, efficient high-level verification languages) may turn out to be even more critical for increased design productivity, than the initial IP reuse. The objective is essentially the same-to avoid designing verification infrastructure for generic IP (standard interfaces like PCI, USB, Ethernet, and so forth) when there is no real value in duplicating this effort. A significant benefit in using the AMBA bus architecture is the availability of an advanced verification environment using high-level verification language and highly automated test bench generation. The verification language Verisity's (Rosh Ha'ain, Israel) Specman verification language improves verification throughput and offers a large number of functional bus models for common interfaces as well as protocol checkers for the AMBA bus. Specman provides a higher abstraction level than HDLs and it covers input (stimuli) generation, automatic checking as well as verification coverage reporting. Specman integrates with common simulators like Verilog and VHDL (event and cycle based) and can access reference (functional) models written in C/C++, Verilog or VHDL, as well as bus functional models (BFM) that are written in Verisity's more hardware/circuit oriented e-code language. The verification environment is partitioned into the peripheral verification environment (PVE) and the system verification environment (SVE). This approach facilitates block-level verification and debug before integrating the block or module with other blocks or modules eventually to full chip level. The Specman test benches facilitate running directive tests to debug functionality, as well as running random tests, in order to find corner cases (see Figure 4). In summary, it should be noted that it's important to leverage available IP for generic interfaces and functions for successful and timely implementation of complex SOC designs. Consideration should be given not only to the IP itself, but to the required verification environment as well. Since the IP market is still relatively small, in terms of the number of users/reuses, it is also important to select vendors and products that have significant market share, thus securing continued and adequate funding for development and quality assurance. Last but not least, a large number of working silicon implementations will further reduce schedule risk and increase design success rate. LSI Logic has a long track record for integrating and reusing LSI Logic and third-party IP. The adoption of the AMBA 2.0 bus will further improve LSI Logic's ability to enable designs that meet customer time-to-market requirements and first-pass silicon.
Bernd Stamme is the product applications manager in the Networking Infrastructure Division's Printing Systems organization at LSI Logic.
| |||||||||
| ||||
All material on this site Copyright © 2001 CMP Media Inc. All rights reserved.
